home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
JCSM Shareware Collection 1993 November
/
JCSM Shareware Collection - 1993-11.iso
/
cl700
/
beta27.lzh
/
README.DOC
< prev
next >
Wrap
Text File
|
1993-04-21
|
30KB
|
1,062 lines
BETA TESTERS MANUAL
<* your software company name here *>
Phone : (###) ###-####
BBS (###) ###-####
Protocol is 9600, N, 8, 1
available 24 hours.
FAX (###) ###-####
ADDRESS : #####################
#####################
#####################
<* NOTE: If No Fax Remove Fax Reference On This Page, Contents,
And In Manual *>
Overview............................................. 3
Testing.............................................. 4
Alpha Testing.................................. 4
Beta Testing................................... 4
What Beta Testing is Not....................... 4
Documentation.................................. 5
Beta Material.................................. 5
Communications....................................... 6
Phone.......................................... 6
BBS........................................... 6
Fax............................................ 6
Not finding any Problems? (IMPORTANT).......... 6
Using the Beta Report Generator...................... 7
Problem Report Format................................ 9
Using the Bulletin Board............................ 10
General Information........................... 10
Uploading Reports............................. 10
Downloading Files............................. 10
Bulletin...................................... 10
Beta Evaluation..................................... 11
End of Beta......................................... 12
On going support.............................. 12
Beta testing future releases.................. 12
Appendix 1 - Testing Ideas......................... 13
Appendix 2 - Sample: Problem Report................ 14
Appendix 3 - Problem Solving Techniques............ 17
Appendix 4 - Trouble Shooting Tips................. 18
OVERVIEW
We have designed these beta procedures, to inform you of how to
use the BETARPT program. In addition, we will outline the
reporting procedures when problems have been found in application
software. Our overall goal is to achieve a streamlined method of
reporting application bugs and making timely corrections.
We understand the time constraints and pressures that our beta
testers are under. We hope that you also realize that we are under
timely pressures as well. There will be times when beta tests will
be pushed back to a later date or given less testing time. We
intend to do our best to prevent this from happening. We want you
to enjoy testing our products while providing us with your input.
We will try our best to follow the procedures outlined. As beta
testing develops and changes, so will the procedures. We will
provide you with updates of the beta report generator and policies
manual as appropriate. We will always welcome any ideas that you
have that will strengthen the communication's channel. Please
contact us if there is something that you do not understand.
Please remember it is a time-consuming task to track all the
problems that beta testers report. If we have trouble recreating
your reported problem, we may ask you for additional information.
The following outlined procedures should keep communications open
and all beta testing aspects tied together.
3
TESTING
Alpha Testing
The alpha testing phase of the application is done by us using
in-house testers before the application goes to outside beta
testers. Alpha testing is designed to make sure that all features
of the product work with other hardware and software that we have
available.
When all the major problems have been found, we then select beta
sites to send the product to for additional testing.
Beta Testing
In beta testing we ask the beta testers to use, as closely as
possible, the application in real world situations. Because of
this approach we have found beta testers provide more variety of
testing to catch cosmetic flaws, compatibility problems, and other
peculiarities about the application. Beta testers use the software
and report anything that is not described by the manual, or seems
to function improperly.
Please keep in mind that no beta software is problem-free. If you
have important information on your machine that cannot be lost, it
is to your advantage to make a backup before testing the product.
WARNING: BE SURE TO HAVE CURRENT BACKUPS OF YOUR DATA.
What Beta Testing is Not
Beta testing is not a phase for redesigning the application. The
primary purpose of beta testing is to find problems the way the
program presently stands. We are always willing to listen to our
customers and will gladly take your comments and suggestions, but
please understand, more than likely, unless there is an extreme
demand for change, you will not see any suggestions implemented
until a future release.
4
Documentation
While going through the application documentation, please let us
know about any inconsistencies that you find when possible. As a
guideline, we need to know about flaws in the documentation within
two weeks after you download the beta material. We do not want to
restrict your comments to this period, but comments need to be
processed immediately. All your manual comments or suggestions can
be put into one report.
Beta Material
Beta test updates are available by calling the BBS. Under extreme
cases we may ship beta material to the latest address that you
have provided. In most cases only the files with bugs will be
available as updates.
5
COMMUNICATIONS
Phone
We use the BBS almost exclusively for the distribution of beta
test software. Previously, we used to take beta reports over the
phone, however; it turned out to be less than organized. If you
have a problem that needs to be resolved by phone, please leave us
a message and we will call you.
Bulletin Board
The Bulletin Board is our primary source of communication. The
number is listed on the cover of the Beta Tester's manual. The BBS
protocol is also listed on the cover of the Beta Tester's manual.
Prior to receiving this beta procedures manual you should have
selected a user name/ID and password. If this did not occur
contact us with your selection.
Fax
We have a Fax number for your convenience. Please use this only
if there is some kind of problem with the BBS. The exception is
if you have material that is better off being faxed such as manual
comments and suggestions. The number is listed on the front page
of the manual.
Not finding any problems
Sometimes especially in the final stages of the beta test its
difficult to find problems. If you feel that you are not finding
any problems, refer to Appendix 1. This appendix should give you
some basic ideas on finding those difficult problems. If you are
still unable to find any problems please contact us by submitting
a report and let us know what you did test and the outcome.
Keeping in contact with us is how we figure out who will be
included in future beta tests.
6
USING THE BETA REPORT GENERATOR
Make a directory called BETA. This is a directory for you to
store the beta report program and its report files.
To run the report program type BETARPT at the DOS prompt. Once
the program is loaded the main menu will appear allowing you to
make your selections. The first time that you run the BETARPT
program you will immediately enter the program and user
information section. Subsequent accesses to BETARPT will not make
you go through these two steps.
Selections are made by pressing the various highlighted function
'F' keys. The following 'F' keys are available:
F1 - Help
F2 - Program Information
F3 - Tester Information
F4 - Problem Description
F5 - Corrective Action
F6 - DOS Shell
F7 - Program Recommendation
F8 - Special Developer Info.
F9 - Save Temp Files & Exit
F10 - Create Report
By making any one of the above selections you will be transferred
to that section. Once transferred a status line is provided to
offer simply instructions. Context sensitive help is provided by
pressing the 'F1' key anytime.
The information below provides a brief explanation of each of the
areas within the BETARPT program.
a. By pressing the 'F2' key you are asked to provide bug
information about the application you are presently testing. You
are asked to be very specific so we may use this information to
attempt to reproduce the bug.
b. The 'F3' key will gain useful information about the system
you are using to test the beta application. Please fill out all
lines as accurately as possible.
c. To describe the bug problem press 'F4'. Please be in-depth
while being brief.
d. The 'F5' key is used to tell us what actions you took to
attempt to correct the noted bug. This includes but is not limited
to removing the AUTOEXEC.BAT and CONFIG.SYS files.
7
e. A DOS shell is provided by pressing the 'F6' key.
f. The 'F7' is provided so you may included specific
recommendations for future releases of the product.
g. In some testing applications the 'F8' will be available to
you. If the Special Developer Info. is not available if will be a
different color than the rest of the selections. If the 'F8' key
is available simply answer all the questions as you did in the
Tester Information area and Program Information area.
h. Pressing 'F9' will save all current files and exit to DOS.
This is useful when you wish to research a particular bug more
thoroughly and do not wish to create a new bug report.
6. To create a report press the 'F10' key. Once you have created
a report, the Beta Report program will create a file called
BETA.RPT. The BETA.RPT file will contain both the report that you
just created and the status of your machine at the time you wrote
the report. This is the file that we need to have uploaded to us.
Once you have written your second report, the report program will
rename your first report to BETA.1. The same situation will happen
for your third report, where BETA.RPT will be renamed to BETA.2,
etc. The most current report will always be named BETA.RPT.
7. When you upload your reports to the BBS, they must be send as
a message to the Sysop or as directed at that time. You will have
to upload the BETA.RPT file in ASCII format.
WARNING : DO NOT COMPRESS YOUR REPORTS IN ANY WAY!! Upload in an
ASCII format only to the message base.
8
PROBLEM REPORT FORMAT
The following tid bits of information are what we would like to
see in the bug problem reports that you will submit. If you give
this type of information when reporting a problem, we should be
more than likely to duplicate the error and not have a need to
call you.
1. Run the BETARPT.EXE program and fill it out all areas that
apply entirely.
2. Describe the problem with a short sentence as complete as
possible. Then if applicable give a keystroke description of how
to reproduce the problem. See Appendix 2 for an example. Read over
your report to be certain it clearly describes the problem,
keeping in mind that we will have to recreate what you submitted.
3. In narrowing down the problem refer to the problem-solving
techniques listed in Appendix 3. By using these techniques it
should help to eliminate possible conflicts that may be created by
TSRs or other nonessential drivers or programs while testing the
application.
9
USING THE BULLETIN BOARD
General Information
The bulletin board is used as the main method of information
exchange between us and the beta tester. We ask that you check the
bulletin board regularly for any new information regarding
upcoming beta tests, or information on current tests.
Uploading Reports
The beta report upload is simple and we require ALL reports to be
submitted to the message base in ASCII format. Any attempt to
compress the files will result in loss of important bug
information.
Downloading Files
Generally, the BBS only maintains applications presently being
tested or individual files of maintenance releases. When a new
file is available for downloading you will be advised of this via
your message box. Please download the file(s) immediately and
delete the message.
Bulletin
On the BBS we have a bulletin that is updated weekly, unless
there is no new information. Please read it occasionally as it
contains important information concerning the status of beta
testing.
10
BETA EVALUATION
During the beta test period, we will be evaluating each tester
based on their participation! If we do not hear from you during
the beta test, you will then be withdrawn from future beta
testing. If you had indicated a preference for testing other
products your name will be removed from those list as well. The
point is please keep in communication with us at all time. It is a
challenge to manage a beta test and we ask for your support.
11
END OF BETA
Beta testers who successfully complete the beta test will, if
possible, receive the final product. Additionally, they will be
notified of the testing conclusion that will generally be posted
on the BBS for a couple of weeks. We consider successful
completion of the beta test means that the tester has found at
least 2 or 3 bugs a week and was active throughout the beta
period.
On going support
After the beta period has ended, all questions can be directed to
the Technical Support Department.
Beta testing future releases
We will always be looking for future testers because the software
will constantly be revised and upgraded to meet our users'
demands. Beta testers who are active in finding problems, give
clear, concise reports and follow these procedures will be given
the opportunity to test future releases.
12
APPENDIX 1
Testing Ideas
1. Test the interface-checking of each button, Function keys,
Quick keys, menu selections, and mouse functionality.
2. Test the on-line and manual help. Refer to the beta
applications README file or manual for where to go to get help
information.
3. Verify all program parameters or command line options.
4. Read the manual and test the described functionality.
5. Test the different configuration options.
6. Review the beta manual for errors and inconsistencies with the
program.
7. If possible, use the program in your everyday environment.
13
APPENDIX 2
Sample Problem Report
BETA TEST REPORT
MyLife Software
Report Created : 12-22-1992 Time : 22:51:52
Report Submission Number: 4
----- TESTER INFORMATION: -----
Name : John Sanders
Address : 704 Rim Drive
City, State, and Zip : Killeen, Tx 76542
Home Phone : (817)634-8569
Home Phone Can Call : X
Work Phone : (817)634-3043
Work Phone Can Call :
Fax Phone : (817)628-2017
System Type : 80386
System Make : Genesis
System BIOS : AMI
System BIOS Date : 09/10/90 System Memory : 8 meg
System Memory Manager : Qemm v6.01
'A' Floppy Drive Size : 5.25HD
'B' Floppy Drive Size : 3.5 HD
Harddrive Size : 210 meg
Harddrive Type : Seagate, IDE
Monitor Type : SVGA
Monitor Maker : Ultra VGA
Monitor Card Maker : Ultra, 1Meg
Operating System : DOS V5.0
File Compression : Stacker v2.0 with card
Modem : X Modem Type : Mx Modem, 2400 Baud
Mouse : X Mouse Type : Prohance, Tracball
Fax : Fax Type :
Scanner : X Scanner Type : The Complete, B&W Scanner
Other : X Other Type : Arcnet Card
----- PROGRAM INFORMATION: -----
Application Name : Decide, V2.0
Program Name : DECIDE .EXE
14
Program File Size : 64325 bytes
Program File Creation Date : 10/02/92
Program File Creation Time : 12:34
Tried Without AUTOEXEC.BAT : X
Tried Without CONFIG.SYS : X
Occurs in Windows : X
Occurs in OS/2 :
Occurs : Sometimes
General Bug Description :
The mouse does not function properly.
----- PROBLEM DESCRIPTION: -----
When accessing certain menu areas the mouse will disappear. I
access a different menu area and return to the main menu and the
mouse will not appear. I have to exit the program in order to get
the mouse to reappear.
----- CORRECTIVE ACTION: -----
I tried removing the Tracball driver and tried several other
drivers. I also attempted to use a Microsoft compatible mouse.
----- APPLICATION RECOMMENDATION: -----
----- AUTOEXEC.BAT file: -----
SET COMSPEC=C:\DOS\COMMAND.COM C:\QEMM\LOADHI /R:1
C:\DOS\APPEND=C:\DOS COPY C:\DOS\COMMAND.COM C:\>NUL
PROMPT $e[1;44;37m*$e[0m$e[41m▀▀▀$e[0m $p$g C:\QEMM\LOADHI /R:1
C:\QEMM\BUFFERS=50 C:\QEMM\LOADHI /R:1 C:\DOS\EMMOUSE
C:\QEMM\LOADHI /R:1 C:\DOS\MOUSE
SET PCTOOLS=D:\PCTOOLS\DATA
SET TEMP=C:\WINDOWS\TEMP
SET LIB=D:\BC7\LIB
SET OBJ=D:\PROBAS\OBJ
SET GMKW=D:\GMKW\
SET COMMUTE=D:\COMMUTE\DATA
PATH=C:\QEMM;C:\DOS;C:\WINDOWS;C:\STACKER;D:\GMKW;D;\CALERA\BIN
MIRROR C: D: E:
----- CONFIG.SYS file: -----
DEVICE=C:\QEMM\QEMM386.SYS R:1 EXCLUDE=B000-BA00 RAM ST:M
DOS = HIGH
SHELL=C:\DOS\COMMAND.COM C:\ /E:512 /P
DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos\ansi.sys
DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos\setver.exe
FILES = 50
15
BUFFERS = 1
DEVICE=C:\QEMM\LOADHI.SYS /R:1 D:\CALERA\CPCSCAN.SYS 3e0 2 1
DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\STACKER\STACKER.COM
C:\STACVOL.000
------------------------ END OF REPORT ------------------------
This is an example of a simple problem report. We realize that
some problems you may encounter will need to be narrowed down, but
since we have a good step-by-step description we also should be
able to recreate it.
Any information you provide about the problem will be very
helpful. If the example information is supplied, there should be
no cause for more information, unless we simply cannot recreate
the described situation.
Keep a copy of your reports for testing updated versions of the
product.
16
APPENDIX 3
Problem Solving Techniques
To narrow down a problem you will need to troubleshoot it. Here
are a few suggestions to get you started.
1. Can the problem be duplicated consistently?
2. Are you running with any memory resident(TSR's) programs? If
so, try running without them. Does the problem still exist?
3. Try rebooting your machine without the AUTOEXEC.BAT and
CONFIG.SYS. Does the problem go away? If yes, use a process of
elimination to find the compatibility problem. (Add CONFIG.SYS and
test, then add AUTOEXEC.BAT and test, etc.)
4. If the application is small enough try using it on another
computer. Does the problem occur on another computer? If not, what
is the DOS and BIOS version and date of the problem computer?
5. Do you have all the necessary files to run the program? Try
reinstalling the program and retest it again.
6. Did the bug occur in an earlier beta version?
7. Could the files be sitting on a bad sector? Copy all program
files to another subdirectory and try again.
These are merely suggestions to help in the debugging process.
If, after trying these suggestions you are still not sure what to
do, let us know what you have tried and what the outcome was. Once
in while you may find a problem that occurs very infrequently, go
ahead and report it. If several people report the same thing we
may be able to find a pattern.
17
APPENDIX 4
Trouble Shooting Tips
Listed below are several items that may help you in trouble
shooting problems with our beta applications:
a. Boot from the 'A' drive and a clean system. If the problem
does not exist then use the process of elimination to determine
the cause.
b. Check for multiple copies or versions of 'COMMAND.COM' on
your drive(s). Remove any that are not used.
c. Reinstall the application on/in a different subdirectory or
drive. If the application works correctly then old files are
either corrupt or the files were sitting on a bad sector of the
disk.
d. Use all command line options.
e. Change the selected video mode.
f. Ensure all cables are correctly secured.
g. Ensure all computer circuit cards are correctly installed.
h. Check all memory chips.
i. Check for interrupt conflicts. It is possible that 2 or
more boards or ports are occupying the same interrupt.
j. Check that the interrupts you are using are set correctly
for the device. Make such LPT1 is using IRQ 7, Comm 1 is using IRQ
4 and Comm 2 is using IRQ 3.
k. Use the DOS program CHKDSK.exe to check the condition of
the harddrive. It is possible you have lost clusters or a
corrupted file allocation table.
l. If you have a conflict with a memory manager such as QEMM
or 386MAX try using command line options that control upper,
expanded, and extended memory.
m. Make sure that no memory conflicts exist. Some LAN cards
require upper memory that is mapped by a memory manager.
18